[译]HTTP/3的前世今生

原文链接：HTTP/3: From root to tip - 2019/01/25

HTTP是一个运行在互联网应用层的协议，其最早在1991年被提出并称为HTTP/0.9。1999年，IETF（互联网工程任务组，Internet Engineering Task Force）推动了HTTP的发展成为HTTP/1.1，相比于HTTP/0.9，HTTP/1.1更加标准化。在接下来的很长一段时间内，HTTP/1.1已经足够好用了，但是不断变化的网络需求需要一个更合适的协议，因此2015年HTTP/2诞生。最近，有消息称IETF想要制定HTTP/3标准，如果你没有紧密关注IETF的工作，你可能会对HTTP/3的突然出现感到震惊和困惑。其实，我们可以通过网络协议的实验和演化脉络特别是QUIC传输协议来追溯HTTP的起源。

如果你对QUIC并不熟悉，我的同事已经从不同角度做了一些很棒的工作。John的博客描述了当今现实世界对HTTP的烦恼，Alessandro的博客整理了网络传输层的一些亟待解决的问题，Nick的博客介绍了如何动手进行一些测试。更多的信息可以访问https://cloudflare-quic.com查看。如果这让你心痒难耐，一定要看看quiche，这是我们自己用Rust编写的QUIC协议的开源实现。

HTTP/3是HTTP在应用层与QUIC传输层所对应的协议。HTTP/3这一名称在2018年10月底提出的第17版草案（draft-ietf-quic-http-17）中提出，并在2018年11月在曼谷举行的IETF 103会议期间进行了讨论并被敲定为正式的官方名称。HTTP/3最早是SPDY over gQUIC，然后其发展为HTTP/2 over QUIC，随后成为HTTP over QUIC，最后更名为HTTP/3。其实，HTTP/3只是一个新的HTTP名称，其工作原理仍然是IETF QUIC，即一个基于UDP的多路复用和安全传输层协议。

在这篇博客中，我们将探讨HTTP/3以前的一些名称背后的历史，并介绍最近的名称变化及其背后的动机。我们将回溯到HTTP的诞生之初的时候，并对其间发生的所有的积极工作进行阐述。如果你想了解全貌，你可以跳到文章的结尾，或者打开这个非常详细的SVG版本来了解。

历史背景

在我们关注HTTP之前，值得提醒的是有两个协议共用QUIC这个名字。正如我们之前解释的那样，gQUIC通常用来标识Google QUIC（原始协议），而QUIC通常用来代表与gQUIC不同的IETF标准进行中版本。

从90年代初开始，网络的需求已经发生了变化。我们已经有了新版本的HTTP，并以传输层安全（TLS）的形式加固了用户的信息安全。本文并不详细阐述TLS，如果你想更详细地探讨这个领域，我们的其他博客文章是一个很好的选择。

为了更好地解释HTTP和TLS的历史，我会整理协议规范和日期的细节。这些信息通常以文本形式呈现，比如用子弹点按日期排序来说明文件标题的列表。然而，有一些分支在时间上有重叠，一个简单的列表不能表达其真正复杂的关系。在HTTP中，一直有多个的重构协议的工作在同时进行，使得重构之后的协议更方便使用，更加适应新的用途，并拥有更好的性能。当你试图将近30年互联网历史中的不同分支的工作连接起来时，你需要一个可视化的东西。所以我做了一个Cloudflare安全网络时间线。(注：专业来讲，它是一个Cladogram，但时间线这个词更广为人知）。

我在创作时加入了一些艺术元素，选择把重点放在IETF领域中那些较为成功的分支上。一些没有显示出来的东西比如W3联盟HTTP-NG工作组的成功，以及一些奇怪的想法，例如有些人热衷于解释如何发音：HMURR（发音为 "锤子"）和WAKA（发音为 "瓦卡"）。

在接下来的几节中，我将沿着这条时间线来解释HTTP历史上的关键章节。在真正从本文获取到有益的信息之前，读者必须了解为什么标准化是有益的，以及IETF是如何对待它的。因此，在回到时间轴本身之前，我们先对这个话题做一个非常简要的概述。如果你已经熟悉IETF，可跳过下一节。

互联网标准的种类

一般来说，标准定义了对某些常见事物的参考条款、范围、约束、适用性和其他内容。标准有多种形式和规模，可以是非正式的（不一定被认可），也可以是正式的（由标准定义组织如IETF、ISO或MPEG同意/发布）。标准被用于许多领域，甚至有一个正式的英国泡茶标准——BS 6008。

早期网络使用的HTTP和SSL协议并非是IETF发布的，这些协议在安全网络时间表上被标记为红色线条。客户端和服务器对这些协议的广泛接受程度使它们成为非正式的标准。

在某种程度上，人们决定将这些非正式的标准正式化（动机将在后面的章节阐述）。互联网标准通常在IETF中定义，它以 "粗略共识和运行代码（rough consensus and running code） "的非正式原则为指导。这种原则的运行是以在互联网上开发和部署事物的经验为基础的，与试图凭空开发一个完美协议的 "clean room "方法形成对比。

IETF互联网标准通常被称为RFCs。这个领域解释起来比较复杂，因此我建议阅读QUIC工作组联合主席Mark Nottingham的博文《如何阅读RFC》。其实，一个工作组或WG，或多或少只是一个邮件列表。

IETF每年举行三次会议，为所有工作组提供时间和设施进行讨论。每次会议的议程可能会变得非常拥挤，可用来深入讨论更深层次的技术的时间有限。为了克服这个问题，一些工作组选择在IETF的两次会议之间的某个月内举行临时会议。这可以帮助保持规范发展的势头。自2017年以来，QUIC工作组已经举行了几次临时会议，完整的清单可在其会议页面上找到。

其他IETF相关人员通过IETF会议也有了见面的机会，如互联网架构委员会或互联网研究任务组。由于近年来IETF黑客马拉松在IETF会议之前的周末举行，这为社区提供了一个为标准开发可运行代码的机会，重要的是，这可以在同一个房间里与其他人进行互操作性测试。这有助于发现标准中的问题，可以在接下来的日子里进行讨论。

就本博客而言，需要理解的重要事情是，RFCs并不是突然出现的。相反，一个RFCs标准的形成要经过一个过程，通常是以IETF互联网草案（I-D, Internet Draft）的格式开始，提交供考虑采用。如果已经有一个已发布的规范，I-D的准备可能只是一个简单的重新格式化的工作。从发布之日起算，I-D的有效期限为6个月。为了保持I-D的活性，新的I-D版本需要被发布。在实践中，让一个I-D过期并没有什么后果，而且这种情况经常发生。这些文件将继续在IETF文件的网站上托管，供任何想阅读它们的人使用。

I-D在安全网络时间轴上以紫色线条表示。每个文件都有一个独特的名字，其形式为：草案-{作者姓名}-{工作组}-{主题}-{版本}。工作组字段是可选的，工作组是可能推进该草案的IETF工作组，有时工作组也会改变。如果一个I-D被IETF采用，或者I-D是在IETF内部直接发起的，其名称就是草案-ietf-{工作组}-{主题}-{版本}。I-D可能会产生分支、被合并或在分支上消亡。草案的版本号从00开始，每次发布新的草案都会增加1。例如，一个I-D的第4个草案，其版本为03。任何时候，如果一个I-D改变了名称，它的版本就会重新设置为00。

值得注意的是，任何人都可以向IETF提交I-D，你不应该把I-D当作标准。但是，如果IETF对I-D的标准化过程确实达成了共识，并且最终文件通过了审查，我们最终就会得到一个RFC。在这个阶段，名字又变了。每个RFC都有一个独特的编号，例如RFC 7230。这些在安全网络时间轴上以蓝色线条表示。

RFC文件是终身不可修改。这意味着对RFC的修改会产生一个全新编号的RFC文件。更改可能是为了纳入勘误表（被发现和报告的编辑或技术错误）的修复，或者只是为了重构规范以改善布局。RFCs可能会淘汰旧版本（完全替换），或者只是更新它们（实质性改变）。

所有的IETF文件都可以在http://tools.ietf.org 上公开获得。我个人认为IETF Datatracker更方便用户使用，因为它提供了一个文档从I-D到RFC的可视化进展。

下面是一个例子，显示了RFC 1945 - HTTP/1.0的发展，它在安全网络时间表有一个清晰的发展过程。

有趣的是，在我的工作过程中，我发现上面的可视化是不正确的。由于某种原因，它缺少了draft-ietf-http-v10-spec-05。因为I-D的寿命是6个月，所以在它成为RFC之前似乎有一段空白，而实际上草案05直到1996年8月还在活动。

网络安全事件线

有了对互联网标准文件如何形成的一点认识，我们就可以开始进入安全网络的时间线了。在本节中，有一些摘录图，显示了时间轴的重要部分。每一个点代表了一个文件或能力被提供的日期。对于IETF文件，为了清晰起见，图上省略了草案编号。然而，如果你想看到所有的细节，请查看完整的时间线。

1991年，HTTP作为所谓的HTTP/0.9协议开始存在，1994年，I-D draft-fielding-http-spec-00被发表，这很快就被IETF采纳了，导致名称改为draft-ietf-http-v10-spec-00。I-D经历了6个草案版本，然后在1996年作为RFC 1945 - HTTP/1.0发布。

然而，甚至在HTTP/1.0的工作完成之前，另外一个单独的活动就开始了，那就是HTTP/1.1。I-D draft-ietf-http-v11-spec-00于1995年11月发表，并在1997年作为RFC 2068正式发表。目光敏锐的人会发现，安全网络时间线并没有完全捕捉到事件的顺序，这是用于生成可视化的工具的一个不幸的副作用。我试图尽可能地减少这些问题。

1997年中期，HTTP/1.1的修订工作以draft-ietf-http-v11-spec-rev-00的形式开始。这在1999年随着RFC 2616的发布而完成。在IETF的HTTP世界里，事情一直到2007年才平静下来。我们很快就会回到这个问题上。

SSL和TLS的一些历史

接下来我们将时间线轨道切换到SSL。我们看到，SSL 2.0规范在1995年左右的某个时候发布，而SSL 3.0在1996年11月发布。有趣的是，SSL 3.0是由2011年8月发布的RFC 6101描述的。根据IETF的说法，这属于历史需要：通常是为了记录那些被考虑过但被放弃的想法，或者决定记录它们时已经是历史性的协议。在这种情况下，有一个IETF拥有的描述SSL 3.0的文件是有利的，因为它可以被用作其他地方的标准参考。

我们更感兴趣的是SSL如何激发了TLS的发展，TLS在1996年11月作为draft-ietf-tls-protocol-00开始存在。它经历了6个草案版本，并在1999年初作为RFC 2246 - TLS 1.0发布。

在1995年至1999年间，SSL和TLS协议被用来保护互联网上的HTTP通信。这作为一个事实上的标准运作得很好。直到1998年1月，随着I-D draft-ietf-tls-https-00的发布，HTTPS的正式标准化进程才开始。这项工作在2000年5月随着RFC 2616--HTTP over TLS的发布而结束。

TLS在2000年和2007年之间继续发展，并制定了TLS 1.1和1.2的标准。在开始下一版本的TLS工作之前，有7年的空白期，该版本在2014年4月作为draft-ietf-tls-tls13-00被采用，在经过28个草案之后，在2018年8月作为RFC 8446 - TLS 1.3完成。

互联网标准化进程

在稍微看了一下时间表之后，我希望你能对IETF的工作方式建立起一种感觉。对于互联网标准形成的方式，一个概括性的说法是，研究人员或工程师设计出适合其特定使用情况的实验性协议。他们在公共或私人场合，以不同的规模对协议进行实验。这些数据有助于识别改进或问题。这项工作可能会被公布，以解释实验，收集更广泛的意见或帮助寻找其他实施者。其他人对这一早期工作的接受可能使其成为事实上的标准；最终可能有足够的动力使正式的标准化成为一种选择。

对于那些考虑实施、部署或以某种方式使用协议的组织来说，协议的地位可能是一个重要的考虑。正式的标准化过程可以使事实上的标准更具吸引力，因为它往往能提供稳定性。管理和指导是由一个组织提供的，比如IETF，它反映了更广泛的经验。然而，值得强调的是，并非所有的正式标准都能成功。

创建一个最终标准的过程几乎和标准本身一样重要。采纳一个最初的想法，并邀请具有更广泛知识、经验和使用案例的人做出贡献，可以帮助产生对更多人有用的东西。然而，标准化的过程并不总是容易的。有一些陷阱和障碍。有时，这个过程花的时间太长，以至于产出不再有意义。

每个标准定义组织往往有自己的过程，是围绕其领域和参与者进行的。解释关于IETF如何工作的所有细节，远远超出了本博客的范围。IETF的 "我们如何工作"页面是一个很好的起点，涵盖了许多方面。像往常一样，形成理解的最好方法是自己参与。这可以像加入电子邮件列表或加入相关GitHub资源库的讨论一样简单。

Cloudflare的行为准则

Cloudflare为能够较早采用新的和不断发展的协议而感到自豪。我们在早期采用新标准方面有着悠久的记录，如HTTP/2。我们还测试实验性或尚未最终确定的功能，如TLS 1.3和SPDY。

关于IETF的标准化进程，在不同网站的真实网络上部署这些运行代码，有助于我们了解协议在实践中的运作情况。我们将现有的专业知识与实验信息相结合，以帮助改进运行代码，并在有意义的情况下，将问题或改进意见反馈给正在对协议进行标准化的工作组。

测试新事物不是唯一的重点。作为一个创新者的一部分，是知道什么时候应该向前迈进，把旧的创新放在后视镜中。有时，这与面向安全的协议有关，例如，由于POODLE漏洞，Cloudflare默认禁用SSLv3。在其他情况下，协议会被技术上更先进的协议所取代；Cloudflare废除了对SPDY的支持，转而支持HTTP/2。

相关协议的引入和废弃在安全网络时间表上以橙色线条表示。竖线有助于将Cloudflare事件与IETF的相关文件联系起来。例如，Cloudflare在2016年9月引入了TLS 1.3支持，最终文件RFC 8446在近两年后的2018年8月发布。

HTTPbis的重构

HTTP/1.1是一个非常成功的协议，时间轴显示1999年后IETF没有什么活动。然而，真正的反映是，多年的积极使用给了实施经验，发掘了RFC 2616的潜在问题，这导致了一些互操作性问题。此外，该协议还被其他RFC如2817和2818所扩展。2007年决定启动一个新的活动来改进HTTP协议规范。这被称为HTTPbis（其中 "bis "源于拉丁语，意思是 "两个"、"两次 "或 "重复"），它采取了一个新的工作组的形式。最初的章程很好地描述了试图解决的问题。

简而言之，HTTPbis决定重构RFC 2616。它将纳入勘误表的修正，并采纳在此期间发布的其他规范的某些方面。我们决定将该文件分成几个部分。最终6个I-D在2007年12月被发布：

• draft-ietf-httpbis-p1-messaging
• draft-ietf-httpbis-p2-semantics
• draft-ietf-httpbis-p4-conditional
• draft-ietf-httpbis-p5-range
• draft-ietf-httpbis-p6-cache
• draft-ietf-httpbis-p7-auth

图中显示了这项工作是如何经过7年漫长的起草过程，发布了27个草案版本，才最终实现标准化。2014年6月，所谓的RFC 723x系列被发布（其中x范围从0到5）。HTTPbis工作组的主席以 "RFC2616已死"的口吻来庆祝这一成就。也就是说，这些新的文件淘汰了旧的RFC 2616。

为什么这么多东西都和HTTP/3有关？

当IETF正忙于研究RFC 723x系列时，外部世界并没有停止停滞不前。人们继续在互联网上加强、扩展和实验HTTP。其中包括谷歌，他们已经开始试验一种叫做SPDY（发音为speedy）的东西。这个协议被吹捧为改善了网络浏览的性能，而这正是HTTP的一个主要用例。在2009年底，SPDY v1发布，并在2010年迅速推出了SPDY v2。

我想避免讨论SPDY的技术细节，不然就跑到另一个话题了。重要的是，你要理解SPDY采用了HTTP的核心范式，并略微修改了交换格式，从而获得了改进。事后，我们可以看到，HTTP有明确的语义和语法划分。语义描述了请求和响应交换的概念，包括：方法、状态码、头域（元数据）和负载（有效载荷）。语法描述了如何将语义映射到电线上的字节。

HTTP/0.9、1.0和1.1共享许多语义。它们也共享通过TCP连接发送的字符串形式的语法。SPDY采用了HTTP/1.1的语义，并将语法从字符串改为二进制。这是一个非常有趣的话题，但我们今天不会在这个兔子洞里走得更远。

谷歌对SPDY的实验表明，改变HTTP的语法是有希望的，而保持现有的HTTP语义是有价值的。例如，保持URL的格式，使用https://，避免了许多可能影响被采用的问题。

在看到一些积极的成果后，IETF决定是时候考虑HTTP/2.0可能是什么样子了。2012年3月IETF第83届会议期间举行的HTTPbis会议的幻灯片显示了所提出的要求、目标和成功措施。它还明确指出，"HTTP/2.0只标志着电线格式与HTTP/1.x的不兼容"。

在这次会议上，社区被邀请分享建议。提交供审议的I-D包括 draft-mbelshe-httpbis-spdy-00、draft-montenegro-httpbis-speed-mobility-00和draft-tarreau-httpbis-network-friendly-00。最终，SPDY草案被采纳，并在2012年11月开始了draft-ietf-httpbis-http2-00的工作。在两年多的时间里，经过18个草案，RFC 7540 - HTTP/2于2015年发布。在这个规范期间，HTTP/2的精确语法发生了分歧，足以使HTTP/2和SPDY不兼容。

这几年是IETF的HTTP相关工作非常繁忙的时期，HTTP/1.1的重构和HTTP/2的标准化是平行进行的。这与21世纪初多年的平静形成了鲜明的对比。请务必查看完整的时间线，以真正体会到所发生的工作量。

虽然HTTP/2正在被标准化，但使用和实验SPDY仍有好处。Cloudflare在2012年8月引入了对SPDY的支持，直到2018年2月，当我们的统计数据显示，只有不到4%的网络客户继续需要SPDY时，才将其废弃。同时，我们在2015年12月引入了HTTP/2支持，就在RFC发布后不久，当时我们的分析表明，有一部分Web客户端可以利用它。

支持SPDY和HTTP/2协议的Web客户端更喜欢使用TLS的安全选项。2014年9月推出的通用SSL有助于确保所有注册到Cloudflare的网站在我们推出这些新协议时能够利用这些协议。

gQUIC

谷歌在2012年和2015年之间继续进行试验，他们发布了SPDY v3和v3.1。他们还开始了gQUIC（当时读作quick）的工作，并在2012年初提供了最初的公开规范。

gQUIC的早期版本使用了SPDY v3形式的HTTP语法。这种选择是合理的，因为HTTP/2尚未完成。SPDY二进制语法被打包成QUIC包，可以在UDP数据报中发送。这与HTTP传统上所依赖的TCP传输方式不同。叠加在一起时，这看起来像：

gQUIC使用巧妙的技巧来达到其现有的性能。其中之一是打破应用层和传输层之间的明确分层。这实际上意味着gQUIC只支持HTTP。以至于gQUIC在当时被称为 "QUIC"，是HTTP的下一个候选版本的同义词。尽管在过去的几年里QUIC不断发生变化，我们稍后再谈，但时至今日，QUIC一词仍被人们理解为是指那个最初的只支持HTTP的变量。不幸的是，在讨论该协议时，这经常是一个混乱的来源。

gQUIC继续被试验，并最终转向了更接近HTTP/2的语法。事实上，如此接近，以至于大多数人干脆称之为 "HTTP/2 over QUIC"。然而，由于技术限制，有一些非常微妙的差异。其中一个例子涉及到HTTP头的序列化和交换的方式。这是一个微小的差异，但实际上意味着HTTP/2 over gQUIC与IETF的HTTP/2不兼容。

最后但并非最不重要的是，我们总是需要考虑互联网协议的安全方面。gQUIC选择不使用TLS来提供安全。相反，谷歌开发了一种名为QUIC Crypto的不同方法。其中一个有趣的方面是一种加快安全握手的新方法。以前与服务器建立过安全会话的客户端可以重复使用信息来进行 "零往返时间 "或0-RTT的握手。0-RTT后来被纳入TLS 1.3。

现在我可以告诉你什么是HTTP/3了吗？

差不多了。

现在你应该已经熟悉了标准化的工作方式，gQUIC也没有什么不同。有足够的兴趣，谷歌的规范被写成了I-D格式。2015年6月，题为 《QUIC：基于UDP的HTTP/2安全和可靠传输》的草案draft-tsvwg-quic-protocol-00被提交。请记住我之前的说法，该语法几乎是HTTP/2。

谷歌宣布将在布拉格举行的IETF 93会议上举办一个 "酒吧论坛(Bar BoF)"。对于那些好奇什么是 "酒吧论坛"的人，请查阅RFC 6771。提示：BoF是Birds of a Feather的缩写。

与IETF接触的结果是，QUIC似乎在传输层提供了许多优势，它应该与HTTP脱钩。应该重新引入各层之间的明确分离。此外，还有人倾向于回到基于TLS的握手方式（这并不是件坏事，因为TLS 1.3在这个阶段正在进行，而且它正在纳入0-RTT握手方式）。

大约一年后，在2016年，一组新的I-D被提交。

• draft-hamilton-quic-transport-protocol-00
• draft-thomson-quic-tls-00
• draft-iyengar-quic-loss-recovery-00
• draft-shade-quic-http2-mapping-00

draft-shad-quic-http2-mapping-00的标题是 "使用QUIC传输协议的HTTP/2语义"，它将自己描述为 "HTTP/2语义在QUIC上的映射"。然而，这是个错误的说法。HTTP/2是在保持语义的同时改变语法。此外，"HTTP/2 over gQUIC "也从来不是对语法的准确描述，原因我前面已经说过了。记住我这里说的话。

这个IETF版本的QUIC将是一个全新的传输协议。这是一项庞大的工程，在一头扎进这种承诺之前，IETF喜欢衡量其成员的实际兴趣。为了做到这一点，2016年在柏林举行的IETF第96次会议上举行了一次正式的Birds of a Feather会议。我很幸运地亲自参加了这次会议，幻灯片并不能说明问题。正如Adam Roach的照片所显示的那样，参加会议的有数百人。会议结束时达成了共识；QUIC将在IETF被采纳并标准化。

第一个用于将HTTP映射到QUIC的I-D，draft-ietf-quic-http-00，采用了Ronseal的方法，将其名称简化为 "HTTP over QUIC"。不幸的是，它并没有完全完成这项工作，在整个正文中出现了许多HTTP/2这个词。I-D的新编辑Mike Bishop发现了这一点，并开始修复HTTP/2的错误名称。在第1稿中，描述改为 "HTTP语义在QUIC上的映射"。

渐渐地，随着时间和版本的推移，"HTTP/2 "一词的使用减少了，实例变成了对RFC 7540部分的单纯引用。往前推两年到2018年10月，该I-D现在是第16版。虽然HTTP over QUIC与HTTP/2有相似之处，但它最终是一个独立的、不向后兼容的HTTP语法。然而，对于那些不密切跟踪IETF发展的人（地球上非常非常多的人）来说，文件名称并没有捕捉到这种差异。标准化的重点之一是帮助沟通和互操作性。然而，像命名这样简单的事情却是造成社区混乱的主要因素。

回顾一下2012年的说法："HTTP/2.0只标志着电线格式与HTTP/1.x的不兼容"。IETF遵循了这个现有的线索。在IETF103会议之前和会议期间，经过反复讨论，达成了共识，将 "HTTP over QUIC "改名为HTTP/3。世界现在处于一个更好的位置，我们可以继续进行更重要的辩论了。

但RFC 7230与7231你对语义和语法的定义有冲突

有时，文档的标题会让人感到困惑。目前描述语法和语义的HTTP标准文件有：

• RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
• RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

我们有可能在这些名称中读到太多的东西，并认为基本的HTTP语义是特定于HTTP的版本，即HTTP/1.1。然而，这是HTTP家族树的一个无意的副作用。好消息是，HTTPbis工作组正在努力解决这个问题。一些勇敢的成员正在进行另一轮的文件修订，正如Roy Fielding所说的，"再来一次！"。这项工作现在正在进行中，被称为HTTP核心活动（你可能也听说过以HTTPtre或HTTPter为名的活动；给事物命名是很难的）。这将把六个草案浓缩为三个。

• HTTP Semantics (draft-ietf-httpbis-semantics)
• HTTP Caching (draft-ietf-httpbis-caching)
• HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)

在这个新的结构下，HTTP/2和HTTP/3更明显的是对通用HTTP语义的语法定义。这并不意味着它们在语法之外没有自己的特点，但它应该有助于为未来的讨论提供框架。

总结来说

这篇博文浅谈了IETF在过去三十年中对HTTP的标准化过程。在没有触及许多技术细节的情况下，我试图解释我们今天所谈到的的HTTP/3。如果你跳过了中间的精彩部分，并正在寻找一个概念性总结，那么它就是：HTTP/3只是一个新的HTTP语法，工作在IETF QUIC，是一个基于UDP的多路复用和安全传输。有许多有趣的技术领域可以进一步探索，但今天我们就到此为止了。

在这篇文章中，我们探讨了HTTP和TLS发展过程中的重要章节，但都是孤立的。在博客的最后，我们把这些章节都拉到了下面的完整的安全网络时间表中。你可以用它来调查你自己的详细历史。而对于超级侦探来说，一定要看看包括草案编号在内的完整版本。